Connectivity Fault Management (CFM) is known to those skilled in the art of telecommunications as a system of signaling messages, comprising standardized methods for testing connectivity among Ethernet ports (or peers). An existing CFM standard IEEE P802.1.ag is based on the assumption that Maintenance Points (MP) can discover their peers by using Continuity Check Messages (CCM) being a type of CFM messages. Another method, used when a destination MAC address of the peer is unknown, is sending multicast CFM messages; such a message is forwarded to all MPs in the domain of the sender and then to all their peers. The CFM messages have a format of Ethernet frames, but a different EtherType.
More specifically, the Standard Draft for Local and Metropolitan Area Networks IEEE P802.1ag/D7 (Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management) describes several methods of Connectivity Fault Management (CFM), that can be used to test connectivity among Ethernet Peers. Ethernet Peers should be understood as Ethernet entities that belong to the same “Shared Medium” e.g., to the same Maintenance Domain for untagged traffic or to the same VLAN and Maintenance Domain for tagged traffic. (VLAN Tag according to IEEE 802.1Q is meant).
CFM uses some a priori configurations to check the Ethernet peers that belong to a shared media. In some cases CFM allows CCM messages to discover peer neighbors, but in such cases CCM cannot be used to identify alien peers. In other cases CFM can operate without configuration of peer MAC addresses and without using CCM messages, say by sending its other message types (Loop Back Messages, Link Trace or Test Messages) to multicast Ethernet addresses. In these cases all receivers of the messages will respond to the sender (being an MP in a Maintenance domain and VLAN). It means that if, in the domain, the link is 1:1 point-to-point link there will be only one response; but if there are many links/peers in the domain as in the cases of 1:N Tree or N:N LAN, many responses will be received at the MP.
The standardized way of operation imposed by CFM creates serious operational problems in network architectures where at least one of the following difficulties takes place:                Some or all MAC addresses cannot be pre-configured;        Users may change MAC addresses without reporting to a network operator; e.g. a user may replace some User Devices (e.g. CPEs, Mobile moderns). As a result, the Network operator cannot track MAC addresses of User Devices since they are often replaced;        MAC addresses cannot be approved for uniqueness, for example two User devices may have the same MAC address rendering CFM unusable.        Part of the network does not support CFM.        
The situations described above are frequently encountered in small networks in which Ethernet is set up automatically without any planned configuration process. They also take place in access networks where modules of Customer Premises Equipment (CPE) belong to users and thus may unilaterally be replaced by them. Networks with nomadic/roaming or mobile Ethernet users are also problematic, since MAC addresses in such networks are continuously updated and hard to track.
A number of approaches were proposed in the prior art, trying to solve the above problems of using CFM messages in access networks.
WO06076493A2 to Alcatel describes a system and a method for monitoring end nodes in an access network, using Ethernet Connectivity Fault Management (CFM). A broadband access server (BRAS) is operable to generate an Ethernet CFM frame that includes a query message with respect to a particular end node. An interworking function (IWF) entity associated with an access node that services the particular end node is operable to interpret the Ethernet CFM frame and construct a corresponding query message in a native protocol compatible with the particular end node. Upon receiving a reply message from the particular end node, the IWF entity constructs a suitable reply Ethernet CFM frame for transmission to the BRAS, wherein the reply Ethernet CFM frame includes a response corresponding to the reply message from the end node.
The interworking function (IWF) in the Access Node will thus divide the maintenance domain into two sub-domains: from IWF to BRAS (which is a CFM compliant sub-domain) and from IWF to a Resident's Gateway RG (CPE) which may be a non-CFM compliant or even non-Ethernet one. In the direction from BRAS to RGs, the IWF will be responsible to translate MAC addresses known to BRAS to “native” messages designated to specific RGs. In the direction from RGs to BRAS the IWF will be responsible for translating the addresses of the RGs to addresses known by BRAS. In this method the IWF “hides” the problem of addressing CFM in access networks. MAC addresses of the end nodes are unknown and remain unknown to BRAS since the CFM messages are always translated in both directions by the IWF.
If BRAS needs to send a CFM message that is planned to reach also unknown MAC addresses, the BRAS will have to multicast a corresponding message to a number of RGs.
Besides that, the fact the Interworking Function in the BRAS performs full processing of CFM messages in both directions, by changing their contents and format, adds to the complexity of the described method.
US2007025256AA to Cisco describes a broadband access node including a port for connection with a Digital Subscriber Line and a processor to run code that implements a so-called virtual maintenance end point (vMEP). The vMEP translates an IEEE 802.1ag Loopback Message (LBM) received from a device on an Ethernet access network into a legacy Operations And Maintenance (OAM) message that is transmitted to a residential gateway (RG) device. The legacy OAM message determines a link-level connectivity status between broadband access node and the RG device. The vMEP also transmits a reply message back to the device on an Ethernet access network in compliance with the IEEE 802.1ag specification. The US2007025256AA introduces a new entity in the Access Node, called “virtual Maintenance End Point”. The virtual maintenance end points reflect the actual maintenance status of a real maintenance point that cannot be reached for various reasons (e.g. missing MAC address, or a different access technology such as ATM, that does not support CFM messages). If BRAS (broadband remote access server) needs to send a CFM message that is supposed to reach unknown MAC addresses, BRAS will have to multicast a corresponding message to a number of RGs.